查看原文
其他

跳槽后接手了个奇葩项目,被坑惨了...

macrozheng 2023-02-06

The following article is from JavaGuide Author 健美猪

大家周末好,今天分享一篇非常有意思的文章。这篇文章来自一位好朋友的投稿,记录了他跳槽之后的一段奇妙的经历,一定要看到最后!!!

11 月下旬入职新公司到现在也已经有一个半月的时间了,入职前,各种担心适应不了新公司,新项目的技术框架、业务流程,入职后才发现,现在手头的这碗饭,真的要好好感谢上一任。感谢他,让现在公司部门里的同事,觉得我是个大神...

项目背景

我新入职的是一家上市公司,有自己庞大的实体产业,但对软件技术要求不高,什么高并发分布式,花里胡哨的,谢绝。内部很多软件用的都是第三方公司开发的成熟 ERP,顶多做做二次开发,唯独我现在接手的这个项目是前任耗时三个多月,前后端一肩挑从零开发的(其实这个周期挺紧的),是的,你没听错,一个人做了一个项目。

你可能会问我为什么要进这种公司,其实我的想法很简单,这家公司虽然给的薪资不算高(现在明显觉得工资要低了,o(╥﹏╥)o),但日常工作作息 855,制度规范,况且我身处三线城市,别说中厂大厂,小厂都没有....

扯远了,以上是项目背景,接下来说说项目使用的框架。

项目框架

当我小心翼翼问技术总监使用什么框架的时候,总监给我的答案是,前端 H-UI,后端用 springboot。

后端我熟,干 java 谁不用 springboot,就是这个 HUI 是什么鬼,怎么不是 vue 之类的东西,然后特意去百度了下,好家伙,还像模像样的,可能是我孤陋寡闻了,从没听说过

其他呢,比如中间件之类的,没有吗?redis 总有吧,没有!

隐隐约约我有种不祥的预感

项目上手

入职的第一天,公司发了台 thinkpad,前任留下的,打开的时候桌面密密麻麻一片,有各种文件夹,安装包,更多的是,一个个 java 文件!!!????

为什么会有这么多 java 文件放在桌面上,什么鬼

后面我就懂了,这个 B 没用版本管理,别说 git 了,svn 都没有,所以桌面上的 java 文件都是他的手动备份...

而且这台电脑前任虽然用过,但是很新,很多开发必备的工具都没有,一问才知道他嫌弃这台电脑配置不行,我一脸懵逼,16G+I5 九代+固态,不算很好但对开发来讲也不错了吧,后面项目实施一脸无奈的告诉我,他喜欢用隔壁办公桌上那台 64G 内存 i7 处理器的台式机(平常用来做虚拟机的),wtf?

在看完他留下的 5 个交接录制视频+还有两天项目实施给我讲解业务之后,开始上手接收项目

吐槽

因为三个多月这家公司没招到合适的人,积压了很多紧急 bug&需求需要处理,事情很急,但我发现在开始码代码之前,有太多的事情得准备....

重要信息记录

给我的文档上就寥寥几行字,一些服务器的地址,账号密码,对这个项目的介绍基本都放在视频里了,而且视频本身讲的也很草率,所以等解决完紧急 bug 和需求后,需要对这个项目进行必要的总结和技术整理,形成文档,万一哪天我也离职了,后人可以翻阅填坑。

版本管理

之前说到没有版本管理,看着桌面上一堆 java 文件,所以第一件事就是在内网搭了 gitlab,把所有的项目传了上去,传完的那一刻长吁了一口气,先不说平时写代码切分支有多方便,至少不用担心如果笔记本炸了代码丢了怎么办的问题......

数据库设计

当我打开数据库的时候发现,所有的表,所有的字段都没有备注,所以赶紧跟项目实施对了一下午的数据库,全部加上了注释(谢天谢地,至少还留了一个懂项目的实施

在盘数据库的过程中,我痛苦的发现他的数据库设计完全不按章法,比如日期类型用 varchar,一些 varchar 字段长度设置 1000(以为这样可以容纳更长的数据????),一些金额、数量字段也用 varchar,有一张表居然全部用了 varchar!!!

真不知道 varchar 上辈子是他的情人还是救了他全家人的命

除此之外,还有一个细节也被我注意到了:没有一张表是加索引的,这个问题后面会说到

代码注释

这个是我接手这个项目最痛苦的地方,往往一个处理方法两三千行(是的,你没看错),光秃秃的,没!有!一!行!注!释!

“我平生最恨两种人,一种是不写注释的,另一种,是逼我写注释的”

有一块业务逻辑是计算月工资,很复杂,各种计件,补贴,考勤,扣款融合算,我相信上任写这块代码的时候也是心情崩溃的,但他的崩溃跟我的崩溃可能不太一样,我的崩溃是:为什么明明这么清楚的逻辑要写的这么复杂!!!明明可以把之前的代码优化下非要用更饶的逻辑去圆已经绕到卷毛的代码!!!

吐槽归吐槽,崩溃的我一行一行读代码,时不时的问问项目实施,隔几行就写注释,边注释边改,勉强度日,想起那些年我做英语阅读理解的日子。

PS:我平时还是比较习惯写注释的,因为很多复杂的逻辑不写注释,后面连自己都会忘记

命名规范、变量定义

我根本不用担心贴代码会造成信息泄露什么的,大家随便看,能看懂算我输

虽然命名是一件头疼的事情,但这么随意合适吗?还有下面这类神仙代码,你根本不知道这里面的 21.75,10,15 都是代表什么意思,这里的操作是为了干什么,如果没有懂业务的实施跟我讲的话真不知道该怎么办。

代码抽象、封装

说实话,这要求对于上任属实有点高,不然也不会出现几千行的直肠子代码,你们看看上面贴的代码心里就会明白,为什么代码又臭又长。

我的看法是,一个处理代码行数超过四五十行,就可以考虑缩减抽离了,为什么要这么做,其实很简单:出于可维护性。一个业务再复杂,离不开一个主干逻辑(也可能是多个)和 N 个子逻辑,你不能把臃肿的子逻辑代码放在同一个处理代码内部,这样太影响可读性,影响可读性的后果就是提高了维护成本。

往往得到一个变量后,我得隔个几十行甚至一两百行才能找到用到它的地方

.....

主处理一

子处理1(假设这里有几百行代码)

主处理二

子处理2(假设这里有几百行代码)
子处理3(假设这里有几百行代码)

主处理结束

....

数据查询处理

前任写数据库查询,大部分都使用 tk.mybatis 做快速查询、修改之类,跟 mybatis plus 有点类似,这本身没什么毛病,都为了提高代码效率,但我很想吐槽的是,明明很好的工具,却被他用的很废:

List<实体类> a = 快速查询全部
List<实体类> b = 快速查询全部
List<实体类> c = 快速查询全部
List<实体类> d = 快速查询全部
....

然后对a、b、c、d一通过滤,然后瞎鸡儿算

现在很多公司,确实因为数据量大的问题,会提倡单表查询,复杂的数据处理都放在 service 层进行,但问题是,从持久层出来的数据应该是经过筛选的,精简数据量。但他没这么做,不管三七二十一,先全部取出来再慢慢用 java 过滤。

而且,这套算工资的系统数据量并不大,现在运行半年了,数据量最大的那张表只有 40 多万(日志表不算),再加上计算工资逻辑复杂,虽然需要关联的表多,如果能够妥善加好索引,在持久层就定义好数据结构,把想要的原始数据处理好,那么逻辑处理也会简单许多。

img

上个月算工资的那几天是最忙的,为什么?因为财务各种反馈接口速度慢,几分钟那是正常的,运行十多、二十多分钟也有,我花了两天时间重构了其中一个核心分支,关联两三表,建好索引,只取需要的字段,重新定义持久层返回的数据结构,最终把需要花五六分钟的这部分处理缩减为几秒,但总的接口处理还是很慢,后续还要花时间去优化(感谢前任让我有做不完的事情)。

数据入库处理

这部分,我不说话,大家看图

代码里充斥着大量的循环插入数据库这种做法,管你是几千几万条数据,劳资就是这么入库的,一年工作经验的都不会犯这种错误吧。

前端列表分页

前端用的 H-ui,先不评判这个框架好不好,但用户反应最多的就是:卡,卡,卡 我一开始是以为是接口问题,虽然发现接口确实很慢,但数据查询完毕返回后页面上还是没有加载出来,后面才发现,一次接收的数据足足有 40 多 m.....

这个 B 没做物理分页!

而且他前端渲染表格的方式是这样的,手动拼接字符串然后填充到网页里

在了解 H-UI 是基于 bootstrap 开发之后,我果断用了 bootstrap-table 去重构前端渲染方式,至少页面这个时候可以渲染出来的,虽然接口还是慢。

而且多刷新几次页面之后,浏览器内存爆表,性能差一点的电脑直接 GG,怎么办?换成物理分页呗,又增加了许多的无端工作量。

但这么多的页面我也不可能全部换成物理分页,只能调问题比较严重的页面进行优化,因为还有那么多 bug 和需求等着我呢....

接口、服务地址切换

这个项目有需要跟第三方系统交互的场景,所以涉及到测试接口、正式接口,然后我发现下面这种现象:

String str_url = 本地测试地址;
//String str_url = 正式地址;

有一个 bug 是因为他测试时忘记切回正式接口地址然后发布到了生产环境导致的...

这种测试的时候忘记切回其实也是一种正常现象,但我们可以通过代码去规避啊,比如把这种 url 参数放到配置文件里,测试环境自动用测试配置文件,生产环境用生产环境的配置文件(原先只有一个 application.yml 文件),还用担心忘记切回的问题吗?

而且为了避免发版出现人为的疏忽错误,我顺便搭了 jenkins 自动化部署,这样就不用担心万一哪天配置文件忘记切到正确环境而引起的灾难性后果。

是人就会犯错,但有工具可以帮你规避,只是前任懒得弄这些。

其他的,redis,log4j2 等一些项目必备工具就不说了,该加的我都加上去了。

工作态度

说一说跟这个行业没直接关联的,职业态度。据同事们讲,平时给他的需求很多都以不能做,做不了为由拒绝,在提出离职后的一个月内,没有修改任何的 bug,完成任何的需求,一直在进行所谓的学习(因为我看到隔壁座位上开了 N 个虚拟机,估计在练集群分布式唬住面试官之类的技术),可能有些人要跟我争论,都打算离职了操这么多心干什么,抱歉,可能我的想法是公司最后一个月也是足额付你工资的,至少我离职的时候也是勤勤恳恳解决当前的 bug、写完交接文档后再走的,直到现在,前同事问我项目上的问题也都是一一解答。

现在 IT 行业很卷,干我们这行的也很辛苦,还要面临公司的剥削和压榨,所以出现很多摸鱼党,这其实也是一种自我保护,毕竟命是自己的,钱就这么点,那么拼干什么。但话说回来,职业道德还是要有,最基本的底线得守住,该摸鱼摸鱼,该上的时候也得上,又不是体制内,能混多久?(个人愚见,所以老板真的也非常喜欢我这种低薪又肯干的老黄牛员工)

致谢

现在的同事潜意识里都觉得我是个非常厉害的技术大佬,但有经验的程序员看到上面我所说的东西都会嗤之以鼻,这些不都是基操吗,还有人要强调这个?我以前也觉得在三四线城市,大家技术水平应该也差不多,好不会好到哪去,差也不会差到哪去,这次的跳槽真让我开阔了眼界。

所以在感慨,在这个行业可能确实需要像前任这样的码农,挖坑,填坑,坑更多了,再填......生生不息,这样行业才能长久生存,没有 bug 可以修复,没有屎山可以铲,我们真的就失业了。如果每个程序员写的文档详细,逻辑清晰,注释清楚,拿什么让老板离不开你,靠什么威胁老板给你高工资,所以我现在的处境用一句话形容:

全凭同行衬托



微信8.0将好友放开到了一万,小伙伴可以加我大号了,先到先得,再满就真没了

扫描下方二维码即可加我微信啦,2022,抱团取暖,一起牛逼。

推荐阅读


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存